\section{Historique et chiffres}

Apple lance son premier iPhone le 29 juin 2007, mais c'est seulement avec la version 2.0
de son \gls{ios} qu'apparaît l'\gls{appstore}, le 11 juillet 2008. "Ceci est une révolution"
comme disait si bien Steve Jobs, en effet l'idée d'un point unique pour le téléchargement
d'application va changer la manière dont les gens utilisent leurs smartphones, et bientôt
leurs ordinateurs (Les dernières versions de Mac OS, ou encore Windows 8 par exemple).

Dans le même temps, fin 2007, Google lance \gls{android}, un système d'exploitation open source pour
smartphones, tablettes (PDA ...) basée sur le noyaux linux. N'étant pas fabriquant de téléphones,
Google crée en même temps l' "Open Handset Alliance", consortium d'entreprises
(Opérateurs de téléphonie mobile, Fabricants de Semi-conducteurs, Fabricants d'appareils)
pour développer des normes ouvertes pour les téléphones mobiles, et par la même occasion
faire adopter \gls{android}. L'\gls{androidmarket}, équivalent de l'\gls{appstore},
sort le 22 octobre 2008.

\gls{rim} ouvre son \gls{blackberryappworld} le 1 avril 2009.

Pour finir Nokia a lancé son \gls{ovistore} en mai 2009, pour les périphériques de chez Nokia fonctionnant avec \gls{symbian}.

\begin{figure}[h!]
\begin{center}
\begin{tabularx}{\textwidth}{|X|X|X|X|X|X|X|}
\hline
\rowcolor{gray}Trimestre & \gls{ios} & \gls{android} & \gls{symbian} & \gls{rim} & Microsoft & Total\\
\hline
2009 Q1 & 3,848.1 & 575.3 & 17,825.3 & 7,533.6 & 3,738.7 & 36,507.4\\
\hline
2009 Q2 & 5,325.0 & 755.9 & 20,880.8 & 7,782.2 & 3,829.7 & 40,971.8\\
\hline
2009 Q3 & 7,040.4 & 1,424.5 & 18,314.8 & 8,522.7 & 3,259.9 & 41,093.3\\
\hline
2009 Q4 & 8,676.2 & 4,042.7 & 23,857.4 & 10,508,1 & 4,202.7 & 53,803.6\\
\hline
2010 Q1 & 8,359.7 & 5,214.7 & 24,069.8 & 10,552.6 & 3,706.0 & 54,301.4\\
\hline
2010 Q2 & 8,743.0 & 10,606.1 & 25,386.8 & 11,228.8 & 3,096.4 & 61,649.1\\
\hline
2010 Q3 & 13,484.4 & 20,500.0 & 29,480.1 & 11,908.3 & 2,247.9 & 80,532.6\\
\hline
2010 Q4 & 16,011.1 & 30,801.2 & 32,642.1 & 14,762.0 & 3,419.3 & 101,150.3\\
\hline
2011 Q1 & 16,883.2 & 36,350.1 & 27,598.5 & 13,004.0 & 2,582.1 & 99,775.0\\
\hline
2011 Q2 & 19,628.8 & 46,775.9 & 23,853.2 & 12,652.3 & 1,723.8 & 107,740.4\\
\hline
2011 Q3 & 17,295.3 & 60,490.4 & 19,500.1 & 12,701.1 & 1,701.9 & 115,185.4\\
\hline
2011 Q4 & 35,456.0 & 75,906.1 & 17,458.4 & 13,184.5 & 2,759.0 & 149,041.8\\
\hline
2012 Q1 & 33,120.5 & 81,067.4 & 12,466.9 & 9,939.3 & 2,712.5 & 144,391.7\\
\hline
\end{tabularx}
  \caption{Vente mondiale de smartphones par OS (en milliers de périphériques).\\Source Gartner \cite{gartner1q10,gartner2q10,gartner3q10,gartner4q10,gartner1q11,gartner2q11,gartner3q11,gartner4q11,gartner1q12}}
  \label{gartner}
\end{center}
\end{figure}

On voit grâce aux chiffres de la figure~\ref{gartner} que les ventes de smartphones connaissent
une croissance phénoménale ces dernières années (multiplié par 4 en 3 ans), et on voit surtout
que 2 OS se détachent: \gls{ios} et \gls{android}. Il y a encore énormément de téléphones \gls{symbian} en circulation,
mais ils ne disposent pas forcement d'un magasin d'applications, de même pour les BlackBerry de \gls{rim},
les anciens modèles ne sont pas compatibles avec le \gls{blackberryappworld}.
Le concept d'App existe depuis peu, et explose en même temps que les deux principales plateformes:
\gls{ios} avec son "\gls{appstore}" et \gls{android} avec son \gls{googleplay}. Ces chiffres expliquent donc la
jeunesse des \glspl{framework} que nous allons voir par la suite.

J'ai commencé mon stage par un état de l'art des outils existants pour le développement d'applications mobiles.
Même si la seconde partie de ce stage allait être le portage d'une application grand publique,
l'idée de cet état de l'art est vraiment de donner une vision claire sur les \glspl{framework} existant,
et de les associer à des usages.

\section{Plateformes}
Au vu des chiffres de la figure~\ref{gartner}, les deux plateformes qui nous intéressent en
priorité sont \gls{ios} et \gls{android}.
Les autres plateformes ont un peu été écartées de l'étude (support facultatif).
Pour illustrer encore cette supériorité, la figure~\ref{statcounter} nous montre qu'en France \gls{ios} et \gls{android}
sont largement devant pour ce qui est de l'utilisation d'internet, ce qui laisse supposer
qu'il en est de même pour les Apps.
\begin{figure}[!h]
\begin{center}
\includegraphics[width=0.8\textwidth]{StatCounter-mobile_os-FR-monthly-200812-201206.jpg}
\caption{Part de marché des OS mobiles sur Internet en France,\\de décembre 2008 à Juin 2012. Source StatCounter \cite{statcounter}}
\label{statcounter}
\end{center}
\end{figure}



\subsection{IOS}
\begin{wrapfigure}{L}{0.1\textwidth}
  \centering
  \includegraphics[width=0.1\textwidth]{apple_logo.jpg}
\end{wrapfigure}

Pour \gls{ios}, le langage de développement est l'Objective-C, une sorte de C objet, donc avec gestion
par le développeur de la mémoire, un code assez verbeux...
Pour l'interface utilisateur, on utilise "Cocoa Touch", \gls{framework} \gls{mvc} qui
s'occupe des animations, du multitâche, de la reconnaissance de gestes ...

Un autre point c'est l'utilisation d'aucun bouton externe dans les applications, l'unique bouton
de l'iPhone/iPad (en face avant) servant à quitter/mettre en arrière plan l'application.

La "navigation" se fait grâce a un bouton précédant qui s'affiche dans la barre de navigation.
En ce qui concerne les versions d'\gls{ios}, tous les périphériques à partir de l'iPhone 3GS ont
le droit aux dernières mises à jour, et il n'y a pas de changements radicaux entre chaque version,
ce qui est un énorme confort pour le développeur.

%simulateur

\subsection{Android}
\begin{wrapfigure}{L}{0.1\textwidth}
  \centering
  \includegraphics[width=0.1\textwidth]{logoandroid.jpg}
\end{wrapfigure}

Pour \gls{android}, on développe en Java, et pour l'interface utilisateur on doit, un peu à la
manière d'\gls{html} et du \gls{css}, définir la "mise en page" dans des fichiers \gls{xml}, très verbeux aussi.

Sous \gls{android} il y a des boutons physiques (ou sur l'écran tactile): "précédent", "maison" et "menu" à minima.
La navigation se fait avec le bouton précédent.

A la différence d'\gls{ios}, les périphériques \gls{android} existent en plusieurs tailles, résolutions,
densités de pixels, et versions (les mises à jour des périphériques sont rares),
ce qui complique le travail du développeur.

Google met à disposition des développeurs les statistiques des versions en circulation
d'\gls{android} (figure~\ref{versionsandroid}), réactualisé tous les 15 jours. Cela nous permet
de décider de supporter \gls{android} uniquement à partir de la version 2.2 (Froyo), comme cela
représente plus de 90\% du parc.
\begin{figure}[!h]
\begin{center}
    \includegraphics[height=0.2\textheight]{androidversions050612.png}
    ~
    \includegraphics[height=0.2\textheight]{androidversions2-050612.png}
	\caption{Répartition des versions \protect\gls{android}, Juin 2012 \cite{androidversions} }
	\label{versionsandroid}
\end{center}
\end{figure}


%emulateur

\section{Cahiers des charges}

Il existe actuellement 2 applications mobiles pour le site internet Lyon Capitale \cite{sitelyoncap},
une application pour Iphone, une pour Ipad.
On veut en plus, a minima , avoir une version \gls{android}. L'objectif est donc de sélectionner
un \gls{framework} de développement mobile pour factoriser au maximum le code et faciliter ainsi
le développement et la maintenance de l'application Lyon Capitale, et d'autres futures applications.

Les contraintes de l'application Lyon Capitale sont pour l'instant:
\begin{itemize}
\item Avoir une interface utilisateur native ! Cette contrainte est très forte et élimine
bon nombre de participants ;
\item Notification PUSH ;
\item « In App purchase» ;
\item Partage communautaire (Facebook, Twitter) ;
\item Utilisation hors ligne ;
\item Requêtes HTTP (requête GET pour le \gls{xml}, requête POST pour les commentaires) ;
\item Lecture audio (mp3) et video (mp4) ;
\item Prise de photos avec l'appareil du mobile si existant (fonction « Mobile reporter »), puis envoie de celle-ci.
\end{itemize}

\begin{figure}[!h]
\begin{center}
    \includegraphics[height=0.4\textheight]{lyoncapold.jpg}
        ~
    \includegraphics[height=0.4\textheight]{lyoncapoldipad.jpg}
	\caption{Anciennes applications LyonCapitale}
	\label{lyoncapold}
\end{center}
\end{figure}

En ce qui concerne les fonctionnalités, les applications s'occupent:
\begin{itemize}
\item d'afficher des listes d'articles, de brèves, de podcasts ;
\item d'afficher ces mêmes contenu en grand ;
\item de lire et télécharger des podcasts ;
\item de lire et télécharger des vidéos ;
\item d'envoyer des commentaires ;
\item de partager les contenus sur les réseaux sociaux.
\end{itemize}


\section{Les frameworks}

Pour chercher des \glspl{framework}, je me suis appuyé sur le tableau comparatif de Markus Falk\cite{markusfalk},
comparatif qu'il a réalisé pour son mémoire de Master, et qui est maintenant mis à jour par
les développeurs des \glspl{framework} eux-mêmes. J'ai aussi lu des rapports comme ceux de la société
Ideo Mobilis\cite{ideomobilis1,ideomobilis2}, de Tribal Labs\cite{triballabs}, avant de parcourir l'Internet
à la recherche d'informations plus précises sur chaque \glspl{framework}.

Comme ce domaines est très jeune, les rapports et autres billets de blog d'il y a 6 mois
sont déjà remplis d'informations fausses, certains projets apparaissent et d'autres disparaissent.
De plus les rumeurs persistent très longtemps sur Internet.
J'ai ainsi dû choisir un nombre limité de candidats pour les étudier plus en profondeur, et j'ai retenu:
\begin{itemize}
\item Mono Droid/Touch (code en C\#, .Net) ;
\item Appcelerator Titanium (code en \gls{javascript}) ;
\item Rhomobile Rhodes (le \gls{ror} du mobile) ;
\item PhoneGap (code \gls{html}/\gls{css}/\gls{js}).
\begin{itemize}
	\item Sencha touch ;
	\item \gls{jquery} mobile ;
	\item ...
	%\item Unify
	%\item nextInterfaces
\end{itemize}
\end{itemize}
Par la même occasion je n'ai pas retenu les \glspl{framework} suivants:
\begin{itemize}
\item Corona: on code en Lua, ce \gls{framework} est destinée à la création de jeux, ou applications hautement graphiques ;
\item Ns Basic/App Studio: l'idée ici c'est de réutiliser ses compétences de développeur \gls{vb},
n'en ayant pas, et le futur mainteneur de l'application non plus, ce \gls{framework} propriétaire
et payant perd donc tout son intérêt ;
\item \gls{gwt} mobile: projet mort/inactif (pas de commit depuis plus de 6 mois) ;
\item beaucoup d'autres projets (mort, trop petit, ...).
\end{itemize}





%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Natif}
Le développement d'application native, seulement à partir du \gls{sdk} de la plateforme,
présente les avantages suivants:
\begin{itemize}
\item[+] Performances maximums ;
\item[+] Taille minimale ;
\item[+] On peut faire tout ce que la plateforme permet ;
\item[+] Charte graphique/convention parfaitement respectée ;
\item[+] Les dernières nouveautés/fonctionnalités sont disponible immédiatement.
\end{itemize}
Mais aussi les désavantages suivants:
\begin{itemize}
\item[-] Les \glspl{sdk} sont assez bas niveaux, ie on doit soit trouver des librairies, soit recoder la roue ;
\item[-] Pour X plateformes, il faut développer X applications ;
\item[-] Chaque plateforme/\gls{sdk} implique un langage de programmation différent, 
un patron de conception différent, des noms différents pour les fonctionnalités  ;
\item[-] Pour X plateformes, il faut maintenir X applications.
\end{itemize}
Ainsi les contraintes principales du développement natif sont les temps d'apprentissage,
de développement et de maintenance, et donc finalement le coût. Ont ne peux rien factoriser, même pour
des applications similaires.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Langage commun, interface native}
L'idée ici, est de factoriser le code métier, toute la logique de l'application, le "moteur",
et de coder cette partie dans un langage/\gls{framework} connu. 

Pour l'interface utilisateur et les fonctionnalités non standard (matériel comme l'accéléromètre, le GPS, ...),
le \gls{framework} propose des \gls{bindings} vers l'\gls{api} native de la plateforme.

\subsubsection{MonoDroid/ MonoTouch}
\begin{wrapfigure}{L}{0.1\textwidth}
  \centering
  \includegraphics[width=0.1\textwidth]{MonoDevelopLogo.png}
\end{wrapfigure}


MonoDroid/ MonoTouch sont des implémentations de \gls{mono} pour \gls{ios} et \gls{android}. Ce sont des logiciels propriétaires
(400\$ par logiciel et par an). Les deux sont des portages de \gls{mono} sous \gls{android} et \gls{ios},
avec des \gls{bindings} vers les \glspl{api} natives et une intégration dans MonoDevelop
(l'\gls{ide} du projet \gls{mono}). Dans chaque application on embarque le runtime \gls{mono} et des librairies de base.

MonoTouch (la version \gls{ios}) est apparu la première fois le 14 septembre 2009, alors que MonoDroid
est apparu le 6 avril 2011.

Le principe est de pouvoir développer en C\#, .Net toute la partie "moteur" de l'application
(dans le cas d'un modèle \gls{mvc}, les modèles et les contrôleurs). Ces outils s'adressent aux
développeurs C\#, .Net qui peuvent ainsi réutiliser leurs compétences. Pour la partie interface,
on doit utiliser les \gls{bindings} natifs de chaque plateforme. Ainsi on doit développer une 
interface utilisateur pour chaque plateforme (\gls{ios}, \gls{android} et Windows Mobile).
Il n'y a pas d'abstraction pour l'interface utilisateur: c'est du  "développement natif en C\#".

Points positifs:
\begin{itemize}
\item[+] Interface native (vraiment) ;
\item[+] Très bonnes performances ("natives") ;
\item[+] Réutilisation compétences C\# / .Net, pas besoin d'apprendre un nouveau langage 
(les développements de l'intranet sont en C\# / .Net, on a donc déjà des compétences en internes) ;
\item[+] Utilisation de \gls{mono} (brique logiciel éprouvé) avec de 'simples' \gls{bindings}: très peu
de bug introduit par le \gls{framework}.
\end{itemize}

Points négatifs:
\begin{itemize}
\item[-] Il faut développer l'interface utilisateur pour chaque plateforme, on factorise seulement la logique derrière ;
\item[-] Pour chaque plateforme il faut comprendre comment fonctionne l'interface utilisateur et les objets natifs (ce sont des \gls{bindings}, les compétences C\# ne suffisent pas) ;
\item[-] Le \gls{framework} fournit uniquement des fonctionnalité de base, comme les \glspl{framework} natifs.
Si on veut par exemple afficher une image distante (depuis une url), il va falloir écrire tout le code pour la télécharger, la mettre en cache, puis l'afficher de manière asynchrone.
\end{itemize}

MonoDroid / MonoTouch sont donc des solutions intéressantes si on a un besoin de performances
et/ou un très gros code "métier" que l'on pourra donc factoriser. L'aspect "coder dans un langage
que vous connaissez déjà (C\#)" est intéressant pour \gls{ios}, car en Objective-C la gestion
de la mémoire est à la charge du développeur, mais moins pour \gls{android} car le Java est
proche du C\#, et que le développeur ne coupera à l'apprentissage du \gls{sdk} (\gls{bindings} ...).



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Langage commun, abstraction de l'interface}
L'idée ici, c'est d'écrire une seul fois votre application, et quelle soit "native", rien que ça!
Bien sur il faudra quelques arrangements mais l'idée c'est que le \gls{framework} fasse 95\%
du travail, et que les fonctionnalités courantes soit fournies par le \gls{framework}. L'exemple 
basique est l'utilisation d'onglets, sur \gls{ios}, les onglets sont en bas, et sur \gls{android},
ils sont en haut. A part cette différence visuelle, il n'y a pas de différence fonctionnelle
majeure, c'est pourquoi le \gls{framework} peut s'en charger, et proposer une abstraction plutôt
que des \gls{bindings}.

\subsubsection{Appcelerator Titanium}
\begin{wrapfigure}{L}{0.15\textwidth}
  \centering
  \includegraphics[width=0.15\textwidth]{appcelerator-titanium.png}
\end{wrapfigure}

Appcelerator Titanium permet le développement d'applications \gls{ios} / \gls{android} depuis Juin 2009.
Sous licence libre (Apache 2), ce \gls{framework} propose de développer une fois pour les deux plateformes
majeures du marché. On utilise pour cela le \gls{javascript} "pur", sans \gls{html} et CCS. Le \gls{framework}
propose une couche d'abstraction pour accéder au matériel et pour utiliser les widgets
(éléments graphiques comme les boutons, listes, ...) natifs \gls{ios}/ \gls{android}.

En plus de cette abstraction, Titanium simplifie vraiment le travail, et est pensée pour
les développeurs WEB, par exemple l'affichage d'une image distante avec Titanium est du
même niveau de difficulté que l'affichage d'une image dans une page web (B + A = BA),
Titanium s'occupe de tout, téléchargement, mise en cache, chargement à la demande
(uniquement quand le cadre de l'image est effectivement à l'écran), image par défaut ...

Le \gls{javascript} est interprété dans un moteur \gls{javascript}, pas dans une webview
(page web ouverte par le smartphone), ce qui permet de meilleures performances.
Appcelerator, la société qui développe le \gls{framework}, propose pour financer les développements
du support, des formations, des services "cloud" et des extensions payantes.

%write once, adapt everywhere

Points positifs:
\begin{itemize}
\item[+] Interface native (vraiment), on crée des objets "\gls{proxy}" ;
%\item[+] Support thème Holo (thème \gls{android} 3 / 4)
\item[+] Performance \gls{ios} 'native' ;
\item[+] Gros travail en cours sur la performance \gls{android} (passage du moteur \gls{javascript} Rhino à V8, correction problèmes performances sur le défilement, ... ) ;
\item[+] \gls{api} d'abstraction facilite vraiment la tâche (par exemple affichage d'images distantes, mise en cache (voir critique Monotouch/MonoDroid)) ;
\item[+] Licence Apache 2 (Open source / gratuit)
\item[+] Extensible: on peut écrire du code natif si des fonctionnalités nous manquent.
\end{itemize}

Un billet intitulé "Why you should stay away from Appcelerator’s Titanium"\cite{titaniumdefault}
peut sérieusement décourager les nouveaux venus. Avec plus de 200 commentaires, très majoritairement
négatifs, et quelques commentaires des "commerciaux" d'Appcelerator, pour dire que tout est
résolu dans la nouvelle version, les points négatifs s'accumulent:
\begin{itemize}
\item[-] Fuites mémoires! Il faut programmer d'une certaine manière pour les évités. A l'usage
je n'ai jamais rencontré de problèmes, en suivant les "Bests Practices" tout va bien ;
\item[-] La documentation de l'\gls{api} est incomplète (en amélioration) ;
\item[-] Le comportement n'est pas uniforme entre « \gls{android} \& \gls{ios} » (en faveur d'\gls{ios}) ;
\item[-] Performance \gls{android} un peu en retrait ;
\item[-] Il faut avoir accès à internet pour lancer l'\gls{ide} (Titanium Studio) ;
\item[-] Les applications ont l'air majoritairement \gls{ios} \cite{appshowcase} ;
\item[-] Je n'ai pas trouvé d'application qui n'a pas l'air d'être écrite 2 fois (+- même visuel, mais boutons différents) quand elles sont « \gls{android} \& \gls{ios} » ;
\item[-] Pas de support des nouvelles fonctionnalités \gls{android} 4 (mais support du thème Holo) lors de l'étude \cite{titaniumcompatibilitymatrix}.
\end{itemize}

Titanium est donc plus ambitieux que MonoDroid / MonoTouch, en proposant une réelle abstraction
de la plateforme. Mais cette ambition, assez grande entraîne plus de risque de bugs, et plus
de limitations, car pour faire abstraction de la plateforme, il faut lisser et on prend
souvent le plus petit commun diviseur, et on sacrifie parfois les spécificités de la plateforme.

Le temps que l'on gagne à développer avec Titanium est en partie perdu en résolution
de problèmes, à cause de la documentation.

La courbe d'apprentissage s'allonge donc à cause de la documentation, et de l'application
de référence, "Kitchen Sink", qui ne suit pas du tout les recommandations. Une autre application
beaucoup moins riche, Tweetanium, suit de meilleurs pratiques (création d'un espace de
nommage pour l'application), mais pas encore les meilleurs pratiques à savoir l'adoption
de CommonJS.

Pour ce qui est des informations, elles sont dispersées entre la documentation de l'\gls{api},
les Q\&A (calqué sur le site Stackoverflow), le wiki, le blog et les "screencasts", ce qui ne facilite
pas la tâche. En revanche les Q\&A sont très efficaces, et c'est en général là que l'on trouve
les réponses à nos interrogations.


\subsection{WebApp}

Avec les WebApp, on prend le pari qu'on peut tout faire avec \gls{html}5, \gls{css}3 et \gls{javascript}.
Le principe: l'application est un site Web statique lancé dans une WebView (fenêtre de navigateur sans bords ...).
L'\gls{api} \gls{javascript} est étendue pour avoir accès au matériel (GPS, accéléromètre, appareil photo, ...),
aux fichiers, ...
On réutilise directement ses compétences de développeur Web, on touche énormément de plateformes,
mais on doit imiter le graphisme de la plateforme, et on ne doit pas s'attendre à des performances
natives.

\subsubsection{Rhomobile Rhodes}

Dans notre cas Rhodes ne présente pas beaucoup d'intérêt mais il présente beaucoup
d'intérêt pour des applications client/serveur avec de forts besoins de synchronisation.
Le langage utilisé est le \gls{ruby}.

Points positifs:
\begin{itemize}
\item[+] c'est la version mobile de \gls{ror} ;
\item[+] environnement de test et de développement efficace et puissant ;
\item[+] forte structuration \gls{mvc} ;
\item[+] licence MIT (open source) ;
\item[+] prise en main très rapide pour les utilisateurs de \gls{ror} ;
\item[+] bonne documentation.
\end{itemize}

Points négatifs:
\begin{itemize}
\item[-] Accès à très peu d'éléments graphiques natifs ;
\item[-] Nécessité d'une librairie pour l'\gls{ihm} .
\end{itemize}

Un autre point négatif dans notre cas est l'absence de développeur \gls{ror} chez Fiducial.
Ce \gls{framework} est vraiment destiné à produire des applications d'entreprise plus que pour
le grand publique.

\subsubsection{PhoneGap}
\begin{wrapfigure}{l}{0.1\textwidth}
  \centering
  \includegraphics[width=0.1\textwidth]{PhoneGapLogo.png}
\end{wrapfigure}

PhoneGap effectue 2 actions: lancer notre site dans une webView, et étendre l'\gls{api} \gls{javascript}.
Il ne s'occupe pas du thème graphique, des animations, de la gestion du tactile, ...
Il faut pour cela utiliser d'autres \glspl{framework}/librairies comme Sencha Touch(GPL ou commercial gratuite/payante) ou
\gls{jquery} mobile (MIT). Sencha Touch est développé par les mêmes développeurs qu'Ext JS, alors que
\gls{jquery} mobile est une extension de \gls{jquery}.

PhoneGap tire partie du fait qu'actuellement presque tous les navigateurs mobiles utilisent le moteur "Webkit", un gros avantage.

Points positifs:
\begin{itemize}
\item[+] Développement en \gls{html}5/\gls{css}3/\gls{js}(compétences existantes) ;
\item[+] Une seul base de code pour 7 plateformes (\gls{ios}, \gls{android}, BB OS, WebOS, WP7, \gls{symbian}, Bada) ;
\item[+] PhoneGap Builder, service de compilation en ligne (première application gratuite),
ce qui évite de maintenir X installations de \gls{sdk} + dépendances, et permet à chaque commit de compiler votre
application pour la tester/la diffuser ;
\item[+] Licence Apache 2 (Open source / gratuit).
\end{itemize}

Points négatifs:
\begin{itemize}
\item[-] Interface utilisateur non native ;
\item[-] Pas d'imitation d'interface utilisateur \gls{android} ! (très bonne imitation \gls{ios} (avec Sencha)) ;
\item[-] Performance très en retrait (non testé) ;
\item[-] Pas d'environnement de développement fournie, PhoneGap n'est qu'une librairie ;
\item[-] Le système de "callback" utilisé par les fonctions de PhoneGap n'est pas forcement
simple à intégrer avec les librairies choisies pour l'\gls{ihm} ;
\item[-] Si on utilise pas PhoneGap Builder, il faut utiliser les \glspl{ide} de chaque plateforme,
créer des projets "PhoneGap" ...
\end{itemize}

PhoneGap est donc un correctif qui vient ajouter au navigateur des fonctionnalités qui seront
certainement de base dans quelques années. En effet on peut dès maintenant accéder
à la position/localisation via \gls{javascript} avec les navigateurs récents. 

\subsubsection{IHM pour PhoneGap}
Pour ce qui est de l'interface utilisateur, Sencha dispose d'un thème "\gls{android}",
mais c'est simplement un changement de couleur par rapport au thème \gls{ios},
les conventions graphiques n'étant pas respectées (Utilisation d'une barre de navigation,
élément inexistant sous \gls{android}). Pour \gls{jquery} mobile, il existe des thèmes pour \gls{ios} et 
\gls{android} mais ils ne sont pas parfaits et donnent une sensation de faux.

%https://github.com/taitems/iOS-Inspired-jQuery-Mobile-Theme
%https://github.com/jjoe64/jquery-mobile-android-theme

\section{Tests et choix}

Les deux seuls challengers retenus pour les tests sont Appcelerator Titanium et MonoDroid/MonoTouch.
En effet PhoneGap est très intéressant, car il adresse 7 plateformes d'un coup, avec une
seule base de code, mais seulement avec une imitation d'interface utilisateur native, 
ce qui ne convient pas à ce projet grand public.


Pour pouvoir différencier le vrai du faux, comme ce sont des domaines qui évoluent très vite
et qu'Internet regorge de rumeurs plus ou moins fondées, j'ai commencé à développer avec
Titanium et Monodroid la base de l'application « Lyon Capitale », à savoir récupération
d'une liste d'articles sur le site de Lyon Capitale sous forme d'un \gls{xml}, affichage de cette
liste dans un tableau défilant, avec de plus les onglets de base. Ce simple exemple m'a permis
de mieux appréhender les 2 \glspl{framework}.

\subsection{Matériel de test}
Les simulateurs/émulateurs \gls{ios}/\gls{android} sont parfois à des années lumières de la réalité
pour tester les comportements/performances des applications. J'avais donc à ma disposition
pour les tests les périphériques suivant :
\label{listemobile}
\begin{itemize}
\item Iphone 4S (\gls{ios} 5.1) ;
\item Iphone 3G (\gls{ios} 5.1) ;
\item Ipad (\gls{ios} 5.1) ;
\item Samsung Galaxy Tab 10.1 (\gls{android} 3.1) ;
\item Samsung Galaxy Nexus (\gls{android} 4.0.4) ;
\item HTC Desire HD (\gls{android} 2.3.3).
\end{itemize}

\subsection{Appcelerator Titanium}


La programmation en \gls{javascript} est au début un peu déroutante, en effet c'est un langage
avec un typage dynamique faible, avec la possibilité d'étendre les objets comme on veux,
la portée des variables assez atypique, les fermetures (closures), les prototypes, ... mais
une fois apprivoisé c'est un langage très puissant, et pas uniquement dans les pages Web.

Pour ce qui est de l'environnement de développement, on utilise Titanium Studio, une version
d'Eclipse avec des extensions (plugins) Titanium. Cela permet en un click de lancer l'application dans
le simulateur \gls{ios} en mode "debug", de compiler l'application et l'installer sur les
périphériques, avoir l'autocompletion pour l'\gls{api} Titanium, et comme c'est une version
d'Eclipse on peut installer les extensions qu'il nous manque, dans mon cas l'extension CVS.
On peut aussi déboguer l'application dans l'émulateur \gls{android}, mais ce dernier est de très
mauvaise qualité et présente souvent des bugs qui n'existent pas sur les périphériques.


Pour les tests j'ai utilisé la dernière stable disponible au moment des tests,
à savoir Titanium Studio 1.0.9.201202141208, avec Titanium \gls{sdk} 1.8.2 (puis version non stable 2.0.0.v20120325213306).


Le \gls{framework} Titanium apporte un couche d'abstraction très puissante :
on a pas à se soucier de savoir si on écrit pour \gls{android} ou \gls{ios}
même si les conventions graphiques diffèrent, par exemple les onglets sont
situés en bas sous \gls{ios}, et en haut sous \gls{android}. Pour créer nos onglets on demande
simplement à Titanium un groupe d'onglets, et on ajoute nos onglets dans ce groupe, et
Titanium fait appel au bon objet graphique natif lui même. De même pour afficher une image
distante, on donne simplement l'url de l'image au \gls{framework} et il se charge de tout,
le téléchargement de manière asynchrone, la mise en cache, l'affichage d'une image par
défaut en attendant. Titanium nous prémâche le travail sur les fonctionnalités basiques,
et est à ce sens un vrai \gls{framework} de développement mobile.


Titanium est assez ambitieux en voulant unifier deux interfaces (\gls{android}/\gls{ios}) architecturer
de manière différente, et c'est un projet encore jeune (début en décembre 2008) ce qui fait
qu'il contient encore des problèmes/imperfections, par exemple avec le \gls{sdk} 1.8.2 le scrolling
(défilement) est très saccadé sur \gls{android} (même sur le Galaxy Nexus, pourtant dernière génération),
ce problème est grandement résolu dans la version 2.0.1.


Il y a donc des problèmes de performances, des différences de comportements en fonction de la plateforme,
il peux y avoir des problèmes de fuites mémoires (il faut suivre certains styles de
programmation en codant pour éviter cela), une documentation succincte et
parfois fausse (fonctionnalités implémentés sur \gls{ios} mais pas \gls{android}).
En revanche l'équipe de développement à l'air à l'écoute de la communauté,
avec un logiciel de suivi de problèmes (bugtracker) ouvert à tous, un planning ouvert, et des priorités en phase avec les
faiblesses actuelles \gls{framework} (Gros travail sur les performances \gls{android}, la documentation,
les différences de comportement entre les plateformes).


\subsection{MonoDroid/ MonoTouch}
Pour les tests de MonoDroid/MonoTouch je me suis limité à MonoDroid car en général les
versions \gls{ios} des produits sont plus abouties, et la plateforme \gls{android} est beaucoup moins
homogène (pour les produits Apple on a un seul thème avec très peu de versions d'\gls{ios}).
L'objectif est de porter l'application « Lyon Capitale » sous \gls{android}.
J'ai utilisé MonoDevelop 2.8.6.5 (\gls{ide}) et \gls{mono} for \gls{android} 4.0.4.264524889 (aussi appelé MonoDroid).


MonoDroid est un portage de \gls{mono} (mise en œuvre open-source de  Microsoft .Net) sur \gls{android},
avec des \gls{bindings} pour l'interface utilisateur et l'accès au matériel. On développe donc en
C\#, langage assez proche du Java, avec les librairies standard .Net (plus précisément de \gls{mono}).


A la différence de Titanium, MonoDroid ne propose absolument pas d'\gls{api} d'abstraction,
mais plutôt une sorte de « développement natif en C\#/.Net ». On peut utiliser à peu près
toutes les librairies/le code C\# que l'on veut, et donc factoriser le code « métier » de notre application,
par contre il faut écrire l'interface utilisateur pour chaque plateforme, ce qui demande
plus de travail, mais permet d'un autre coté des performance maximum, et une application vraiment native.


Un autre problème de ce portage « brut » de \gls{mono} sur \gls{android} c'est que .Net n'est pas un
\gls{framework} de développement mobile. Ainsi, lorsque l'on va vouloir afficher comme avec
Titanium un tableau avec dans chaque ligne une image et plusieurs lignes de texte il va falloir
pour \gls{android} créer un classe « adaptateur » pour remplir ce tableau, définir la structure
de chaque case dans un \gls{xml}, puis on va pouvoir factoriser le code qui : crée un client http,
va chercher l'image de manière asynchrone , la met en cache, et l'affiche dans la bonne ligne.
Le développeur doit donc gérer des problèmes de programmation parallèle (multithreading), de sémaphores, et de nettoyage
de cache pour simplement afficher des images distantes.

En revanche une fois ce travail bien exécuté les performances sont excellentes. Si en
revanche on travaille mal, le débogage d'application multi-processus a tendance a faire planter
le débogueur, et est toujours un exercice pénible.


Il existe des librairies comme MonoTouch.Dialog qui gèrent le problème cité plus haut mais
son équivalent \gls{android} (MonoDroid.Dialog) est comme d'habitude moins abouti,
et ne gère pas, par exemple l'affichage d'image distantes.


\subsection{Choix}
Pour conclure le choix de Titanium permet d'accélérer le développement et la maintenance du code
(1 seule base de code pour 2 plateformes), mais nous rend très dépendant du \gls{framework}
(qui peut introduire des bugs ...). D'un autre coté on profite des améliorations simplement en recompilant le code.


Le choix  de MonoDroid/MonoTouch fait reposer 200 \% du travail sur le développeur,
qui doit coder plusieurs fois l'interface, et coder une fois les fonctionnalités de base.
En revanche comme le \gls{framework} est moins ambitieux (il n'y a pas d'abstraction,
simplement des \gls{bindings}), il n'est pas un sujet d'inquiétude.


Avec mon maître de stage, Philippe Noel, nous avons donc décidé de se risquer à l'utilisation
de Titanium, qui présente un rapport qualité prix très intéressant. 

MonoDroid/MonoTouch reste intéressant mais pour des applications où la partie "moteur"
est suffisamment grande ou complexe.

PhoneGap, ne proposant pas d'interface vraiment native, sera bien dans les projets où le contenu /
les fonctionnalités sont un réel plus (trouver la station de Velov non pleine la plus proche ...),
et ou on veut toucher un maximum de publique, avec un temps de développement court.
Mais avant de développer un application avec PhoneGap il faut se demander si un bon
site web mobile ne serait pas mieux.
